This happened to me quite a few years ago, when I was a relatively new manager. Early one morning, I was in my office, doing manager things. Suddenly, one of my supervisors burst through the door and shouted, “Why did you fire my programmers?”

That was a lively start to the day, especially before coffee. I knew I hadn’t fired anyone. Had I? Still, I worked for a big company, and anything could happen. Had I missed a headcount meeting?

“Sit down,” I said, which was stupid, because she’d already plunked into the nearest chair, glaring at me. “Were they contractors?”

“Yes.” I knew that tone, the one your spouse uses when you ask whether the sky is blue. Behind the Yes she was silently screaming, “Of course they’re contractors, you idiot! You can’t fire employees, only HR does that!”

I was not making a great impression here. Shadow of the leader, indeed. I slogged ahead: “Why do you think they’re fired?”

“Because they told me!” (How did you get to be manager, again?)

“Uh, OK, why do they think they’re fired?”

“Because they came into work this morning, and all their equipment was gone! Both their desks were clean!”

First clue. Theft? The building was badge-access. Besides, contractors got Company-issued desktop computers, hardly known for sporting the latest technology. They were too bulky and not worth the risk. So maybe zero tolerance? We had a few rules — hostile workplace, inappropriate use of technology, etc. — that could cause a contractor to be fired on the spot. Even so, I’d have known. Somebody would have had a conversation with the contractor rep.

I kept searching.

“Was anything else missing? Besides the equipment?”

“No.” She got up. “They put everything away at night. Everything. Even their family pictures. They clean off their desks.” As she headed to the door, she said, “Look, I’m going to have to tell the team something. They’re all confused. What do we do?”

“Don’t do anything yet. I didn’t fire anybody. Tell the contractors to hang on, we’ll figure it out.”

“OK, let me know.” She left.

Figure it out. Right. What was going on here? Then it hit me. They put everything away at night.

I searched email and found the memo, one of those things that periodically get sent out after some exec or other has expressed an opinion about the state of the office, usually after some scintillating commentary in a professional journal. A new best practice. Sigh. This one said:

1. As professionals, we are expected to maintain a clean work environment
2. Therefore, desks should be cleared of all papers, etc., at the end of each workday
3. Failure to follow this policy could result in disciplinary action

There it was. In our company (and I suspect this is similar in any company), contractors knew that their lifeline could be cut for any or even no reason. They also knew what it meant to be on the receiving end of “disciplinary action.” So they tended to follow the rules scrupulously. That meant that, every day, those two contractors cleared everything off their desks: no pens, pencils, pictures or papers were left out. Those desks were empty. Not even dust collected there.

That shouldn’t have been a problem. However, in addition to the new “clean your desk” policy, we had an existing practice, intended to ensure we were efficiently managing our leased desktop computers. That meant being on the lookout for desktop computers sitting at locations where there appeared to be no business activity. In other words, desktop computers sitting on clean desks. We had a “PC Police” team dedicated to making random sweeps of buildings looking for candidates. When they found them, they confiscated them.

In a nutshell, this what had happened:

1. New “clean desk” policy issued
2. Contractors, being paranoid, uber-follow the rules, clearing everything at day’s end
3. After hours, PC Police come along, see empty desks with computers, and confiscate them
4. Contractors arrive the next morning, see their equipment is gone, and figure they’re fired
5. Contractors beseech supervisor, who bursts into my office and etc.

The story had a happy ending. We located the computers in storage before the next best practice swung into action. That third best practice involved promptly and forensically wiping the drives of any computers in storage, so that they could be redeployed. That best practice would have effectively wiped out months of work and set our project back indefinitely.

As it was, we only lost a couple of days. By the grace of a bit of bureaucratic inefficiency, we were saved.

What had really happened, though?

In a word, best practice collision. Why? Because we hadn’t done systems thinking.

There’s a classic cartoon in systems thinking:



(I’m looking for the attribution, but I found the cartoon here, among other places.)

That’s what happened here. Best Practice #1 (Keep a Clean Professional Workplace) collided with Best Practice #2 (Confiscate Abandoned PCs) and nearly got done in by Best Practice #3 (Promptly Erase Data from unused PCs to eliminate risk of data theft / privacy breach). Specifically, a key output of #1 (a clean desk) satisfied an input condition for #2 (an abandoned PC).

You could, I suppose, add a Paranoid Contractor Best Practice, with input = Follow the Rules or Else, action = Make the Desk So Clean You Can Eat Off It, and result (theoretical in this case) = Don’t Get Fired. Imagine their surprise when their Best Practice returned a result opposite of their desire. That’s what happens when systems collide.

Contrast this with two employee Best Practices: (1) I’ll Clean Up When I Get Around To It; and (2) I’ll Just Ignore This Policy Until It Goes Away. Neither of these are likely to return a key output / input = clean desk. And even if the PC had disappeared, the employee is likely to raise a stink while tacitly assuming he or she is still employed.

The point of this silliness is this: It’s easy to create solutions that themselves create additional problems. What’s harder is to discover unintended consequences. This is true of well-meaning public policy, new technology, process improvements — the list goes on.

In our quest for speed and micro-delivery, one wonders if there will be an accumulation of changes in direction or in unintended impacts that will accompany advances. Should we stop? No, but perhaps occasionally we should Look and Listen. Time spent discovering possible impacts of change may well outweigh time spent correcting actions later.

Then again, think about this pair of sayings: Look Before You Leap; and He Who Hesitates Is Lost. Like so many things in life, strategy formulation and its risk-taking cousin are more art than science. Our history records far more of the doings of those who succeed than the efforts of those who missed the mark. And razor-thin are the lines between the one who stopped before success, the one whose persistence hit pay dirt, and the one who went “a bridge too far.”